アカウント設計プラクティスのご紹介（LIFFアプリ・LINEチャットボットアプリの場合）

はじめに

アノテーション の中野です。

クラスメソッドグループではLINEを活用したLINEミニアプリ、LIFFアプリ、LINE Botの開発、技術支援をおこなっています。

LIFFアプリやLINE Botに対するシステム側のアカウント設計について、実践的なプラクティスがあまり情報がなかったため、まとめてみました。

ターゲット読者

• LIFFアプリやMessaging APIを使ったLINEチャットボットを使ったサービスを作りたい人
• 商用環境のLIFFアプリやLINEチャットボットアプリのアカウント設計方法に迷っている人

前提

やること

• LIFFアプリ、LINEチャットボットのアカウント設計のプラクティス紹介

やらないこと

• LINE公式アカウントのプラクティス紹介
• LINEミニアプリ（LIFFアプリではない）のプラクティス紹介
• LIFFアプリやチャットボット作成のためにプロバイダーやチャネルの具体的な設定方法

用語の整理

LIFFアプリとLINEミニアプリの違い

LINEミニアプリは、スマートフォンのLINEのアプリのみで動作するWEBアプリケーションです。

一方で、LIFFアプリは、LINE上のブラウザでも外部ブラウザでも利用できるWEBアプリケーションです。

LINEミニアプリはLIFFアプリと違って、公開には審査やLINEアプリのみの表示しかできない制約がありますが、独自の機能が利用可能なメリットがあります（例：Service Messageなどの無料のメッセージ送信。ただしテンプレートを利用）

LINE Bot

LINEが提供するMessaging APIを利用して、LINE上のメッセージに応じたチャットボットを作成できます。

対象のLINE公式アカウントからアクションを受け取ると、LINEプラットフォーム側でリクエストを独自で開発したシステムへリクエストを転送します。

このリクエストの転送を、Webhookといいます。

Webhookイベントを利用して、独自開発したシステム側で特定のLINEユーザーへ対して応答メッセージ（replyMessage）やプッシュメッセージ（pushMessage）を配信できます。

プラクティスのご紹介

前提として、設計のプラクティスについて、弊社で構築した複数プロダクトのナレッジを元にしています。

使い方によっては、プラクティスが当てはまらない場合がありますので参考程度にご活用ください。

より詳細なアドバイスや細かなご要件があるなど、相談をご要望場合は弊社のLINEサービス総合支援までお問い合わせください。

なお、プラクティスのイメージできるように全体の設計図を作成しています。以下、全体設計図をもとに、各プラクティスを紹介します。

1. 本番用プロバイダ（ステージングも含む）と開発用プロバイダを分離する

LINEのアカウントは、本番用のプロバイダと、開発用のプロバイダに分割することをおすすめいたします。

主にセキュリティ面を考慮して開発用プロバイダを分けています。

開発メンバーに開発用プロバイダのAdmin権限を付与することで、不用意な操作による障害のリスクを軽減できます。

ステージングと本番は、同一プロバイダを利用しています。

ステージング環境は本番同等の環境として本番不具合の再現テストなどを実施するためです。

これによって同一のLINE UserIDによるステージングでの検証が可能です。

2. LIFFアプリの構成基盤はアカウント単位（本番アカウント、ステージングアカウント、開発アカウント等）で分離する

こちらも上述の内容と同様ですが、開発者が誤って本番環境を不用意に触れてしまうということを回避するためです。

また、AWS CDKやTerraformなどのIaC（Infrastructure as Code）を利用することで、各環境で同一設定による構築できますのでご検討ください。

（参考として、私達のLINEアプリ保守チームでは、インフラ・バックエンド・フロントエンドをTypeScriptでコーディングできることから、AWS CDKをメインで利用してます）

開発者のローカル環境でスピーディーにLIFFアプリのフロントエンドを開発されたいという場合には、以下ブログが参考になるかとおもいます。

3. LIFFアプリのフロントエンドやLINE BotサーバーのURLは、各環境ごとサブドメインで区切って利用

本番環境のネームサーバに登録したドメイン example.com を、各環境のアカウントにサブドメインで委任させているため、stg.example.comとなっています。

各環境に委任されたサブドメイン（例：stg.example.com）のアカウント内で、apiなどの用途ごとにサブドメインをさらに切っているため、設計図のURLのapi接頭辞がつくようになってます。

参考：

弊社で構築したLIFFアプリは、SPA（シングルページアプリケーション）にて構築する場合が多いです。

各環境のLIFFアプリは、サブドメインで区切ってルーティングをおこなっています。

例えば、フロントエンド側の開発環境では、https://dev.example.com のようにして、SPAのページへルーティングされるようにDNSで設定します。　

一方で、バックエンド側の開発環境は、https://api.dev.example.com のようにして、SPAからみたときのバックエンドのAPIへルーティングされます。

LIFFアプリで、ページの切り替えはパスルーティングにて実現しています(例：Reactの場合、React Router)。

例えば、ログインページを表示するときは、フロントエンドのパスは https://example.com/login のようにします。

ログイン表示後のログイン処理で、フロントからバックエンドへフェッチ（例：Reactの場合、Tanstack Query）する際のパスは、https://api.example.com/login という形で問い合わせます。

さいごに

ここまでご紹介したのはLIFFアプリやチャットボットアプリの一般的なアカウント設計の事例をもとにしたご紹介でした。

仮に、細かなニーズを満たすミニアプリやLIFFアプリを作ってほしいなどございましたら、こちらまでお問い合わせください。

アノテーション株式会社について

アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。

当社は様々な職種でメンバーを募集しています。「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイト をぜひご覧ください。